Users can have access rights to various items: units, groups of units, resources and accounts, routes, and other users. Depending on the available rights, the user can view and take some actions on a particular item.
Most often, full access to the unit (all rights) have only those users who configure it, while other users have limited rights sufficient to work with the unit. To avoid the incorrect changes of settings, it is important to assign to users only those rights that they really need.
Observed issue and the method of solving it
In everyday work, the rights to the unit are defined appropriately and do not change. However, there may be difficulties when changing rights, or sometimes rights can change without your participation, and the resulting settings may differ from what you expect. In this article, we'll consider standard issues of this kind. Choose one of the options below according to the situation you are experiencing.
1. After reducing the rights, the user still has more rights
A unit can belong to the group, towards which the user also has rights. In this case, the user will possess a wider list of rights of the two possible.
To correct the situation, try excluding the unit from the group or removing user rights to the group that the unit belongs to. After making these changes, set the desired rights towards the unit again.
A unit can belong to several groups at once, and in this case, it is recommended to check the user's rights towards all these groups. The list of groups that a unit belongs to is displayed on the Groups tab in the unit properties.
2. When removing all rights to a unit, an error is displayed and the changes are not applied
Most likely, this user is the creator of the unit. At the moment, it is impossible to remove from the creator all the rights to the item created by them. If you try to do this, an error will be displayed with the text "You cannot withdraw access rights from the creator of an object".
To correct the situation, you need to change the creator of this unit. To do this, you can transfer the unit to another account. The unit must be in the account of a user who directly uses this unit.
We’ve created a video on how to use the Switch account tool from the management interface (CMS):
3. When extending the rights, changes are not saved
Wialon uses the following hierarchy principle: it is impossible to give a user more rights to a certain item than the creator of this user has to the same item. If you extend the list of rights, but the changes are not saved, it may mean that the user's creator doesn't have enough rights to the unit.
To correct the situation, assign a wider list of rights towards the unit to users who are higher in the hierarchy. After that — to the user, who needed to extend the rights (that is, go through the entire branch of the account hierarchy from top to bottom).
You can check the service structure using the Service Hierarchy tool in the management interface (CMS).
4. Rights change even though you don't make changes
To change access rights to a unit, the user must have the Manage access to this object right towards that unit. Multiple users can have access to a unit simultaneously. Accordingly, several users can make changes. You can track changes using the Log, which you can view on the Messages tab or in a report using the same-name table.
To correct the situation, analyze the Log and disable the ability to change access rights for those users who should not do this.
5. Rights change even though no user is making changes
Most often, such changes may occur in a certain equal period or under certain conditions. In this case, the reason is the work of Jobs with the Change access to units type or Notifications with the action method Change access to units or Add or remove units from groups.
To correct the situation, check that jobs and notifications are configured correctly (if necessary, you can delete or stop them).
6. Rights change even though users, jobs and notifications don't do this
Wialon has the ability to change item settings (including changing rights) via API requests. Such requests are still executed on behalf of a specific user, at the same time, logging in and out of the system using an API request to some third-party application is logged. This information can be tracked in the user properties on the Log tab or in the management interface (CMS) on the Users tab in the Last visit column.
To correct the situation, analyze the operating logic of the third-party application. If the application uses a user token created specifically for working with a third-party application, then this user can change the list of rights and disable the Manage access to this object right, or change the flags of their token. If the application uses the token of the same user that is used to enter the monitoring interface, it is necessary to revise the application logic, getting rid of changing user rights towards units.
Log entries can be deleted. In this case, information about changing rights will not be displayed. If you suspect that you’ve faced such a situation, please contact Wialon technical support via email support@wialon.com.